release: engine v1.1.0 - #328
Merged
Merged
Conversation
The v1.0.0 tag can no longer be moved. ADR-0017 §5 permitted one re-tag on the stated precondition that the engine was unchanged, and recorded four observations so a future reader could re-check rather than trust the ruling. Observation 1 now fails: #321 moved 14 files and 879 lines under crates/compiler/src and crates/dsl/src. Measured rather than argued: building nobodys-cave-island with the engine at the current tag and at main differs by 49 emitted files — barks and sequences the old engine silently dropped because its walkers saw 4 of 5 effect roots. Moving the tag across that would be a silent re-release, not bookkeeping. §5 said this in advance: 'Future engine releases move forward by version.' Owner decision 2026-08-07: v1.1.0, not a patch — emission behaviour changed. Datapack-neutral, measured against the build the owner is playing: baseline (stage/r22-batch, delvec 1.0.0) cf882e2e6840...b337a45 same tree with this bump (delvec 1.1.0) cf882e2e6840...b337a45 The version string reaches exactly one output file, manifest.json; no byte of the datapack carries it. requires.delvec stays '>=1.0.0 <2.0.0' — a major window, per ADR-0016.
stellarfeline
added a commit
that referenced
this pull request
Aug 8, 2026
…ease path looked (#335) `#328` raised `delvec` to 1.1.0 in `crates/compiler/Cargo.toml` and did not update `Cargo.lock`, which still recorded 1.0.0. Every `--locked` build then fails by design: error: cannot update the lock file ... because --locked was passed The v1.1.0 tag's `shelf` job failed on all five targets for this and nothing else. No release was created and nothing was published, so the tag is being re-cut rather than worked around. ## Why no gate saw it `--locked` appears exactly once in this repo: inside `tools/build-release-binaries.sh`, which only the release workflow runs. Ordinary CI ran `cargo clippy/test/build` WITHOUT it, so cargo silently repaired the lock on every runner and every developer machine, and the drift merged green. A defect that is only observable on the release path is a defect discovered by tagging — the most expensive place to find one. So `--locked` now rides every cargo invocation in `ci.yml` (clippy, test, the delvec build, the prefab-generator test). A manifest/lock drift is an ordinary red on the PR that introduces it. ## Debugging note worth keeping This took several wrong turns because **the first command run against it destroyed the evidence**: a plain `cargo build` (no `--locked`) silently rewrote the lock in the working tree, so every subsequent local reproduction ran against an already-repaired tree and passed. Local-vs-CI divergence was then blamed on the target triple, the toolchain pin, transitive git deps, and an empty cargo cache in turn — all disproved, all costing a round. When a check exists to detect drift, run THAT check first; a repair tool run before the diagnostic is a deleted finding. Red -> green demonstrated on the motivating scenario: with the lock reverted to its state at the tag, `cargo build --locked -p delvec` reproduces the exact CI error; with the lock updated, it is green. Claude-Session: https://claude.ai/code/session_01AjQ5p1Kv5MrkGPumi7yXWL Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why a version, not a re-tag
ADR-0017 §5 allowed one move of the
v1.0.0tag, on an explicit precondition — the engine at that version is unchanged — and recorded four observations "so a future reader can re-check them rather than take the ruling on trust."Re-checking today, observation 1 fails: #321 moved 14 files / 879 lines under
crates/compiler/srcandcrates/dsl/src.Measured, not argued. Built
nobodys-cave-islandwith the engine at the current tag (922cfb6) and atmain:49 files only in the new build, 2 only in the old, 2 differing (
manifest.json, one generated PackTest). The new files are player-facing content — NPC barks with real dialogue, and aseq_*family — that the old engine silently dropped because its walkers enumerated 4 of 5 effect roots. #321 fixed that, and the shipped island has been missing those lines.Moving the tag across that would be a silent re-release. §5 anticipated exactly this: "Future engine releases move forward by version." Owner decision, 2026-08-07: v1.1.0, not a patch — emission behaviour changed.
v1.0.0therefore keeps an empty shelf permanently. §5 declined1.0.1to avoid that; the cost is now unavoidable and is paid knowingly.What moves
versions.toml [engine].version,crates/compiler/Cargo.toml [package].version, and the skill'sverified_with.requires.delvecstays>=1.0.0 <2.0.0— a major window (ADR-0016), so a minor engine bump does not move it.delvewright-dslstays0.1.0on its own line (ADR-0017 §2).Datapack-neutral, and measured against the build the owner is playing right now
Identical. The version string reaches exactly one output file —
manifest.json— and no byte of the datapack carries it. This is the first application of the released-campaign byte baseline the owner approved today: anything that moves a datapack byte re-enters her playtest batch, and "byte-neutral" is measured, never asserted.What CI proves
validation/check-versions.shbinds the four numbers ADR-0016 requires to be one number;tools/check-skill-version.pybinds the skill's window. Both pass locally with the new value.